commit 720324fbde9db01809d09f823db683b6b6729314
Author: Leon Hwang <[email protected]>

bpf: Fix possible memleak when updating local storage maps with BPF_F_LOCK

This patch fixes a memory leak when updating local storage maps with
BPF_F_LOCK by calling bpf_obj_free_fields() after copy_map_value_locked()
to properly release old special fields like BPF_KPTR_{REF,PERCPU}.

> diff --git a/kernel/bpf/bpf_local_storage.c b/kernel/bpf/bpf_local_storage.c
> index b931fbceb..2b7bd47e9 100644
> --- a/kernel/bpf/bpf_local_storage.c
> +++ b/kernel/bpf/bpf_local_storage.c
> @@ -609,6 +609,7 @@ bpf_local_storage_update(void *owner, struct bpf_local_storage_map *smap,
>  		if (old_sdata && selem_linked_to_storage_lockless(SELEM(old_sdata))) {
>  			copy_map_value_locked(&smap->map, old_sdata->data,
>  					      value, false);
> +			bpf_obj_free_fields(smap->map.record, old_sdata->data);
>  			return old_sdata;
>  		}
>  	}

Does the same issue exist in the locked path later in this function?

In bpf_local_storage_update(), there's a second location where
copy_map_value_locked() is called with BPF_F_LOCK (around line 642-646
in the patched version). This path also updates old_sdata->data in place:

	if (old_sdata && (map_flags & BPF_F_LOCK)) {
		copy_map_value_locked(&smap->map, old_sdata->data, value,
				      false);
		selem = SELEM(old_sdata);
		goto unlock;
	}

This appears to be the same pattern as the fixed code above - it calls
copy_map_value_locked() to update in place, but doesn't call
bpf_obj_free_fields() to free the old special fields. Can the old kptr
fields leak here too?

Both paths handle in-place updates with BPF_F_LOCK:
- Line 609-613 (lockless fast path): copy + free (fixed by this patch)
- Line 642-646 (locked slow path): copy only (missing free?)

The hashtab code in kernel/bpf/hashtab.c has a similar pattern at lines
1124-1127 and 1153-1156 where copy_map_value_locked() is followed by
check_and_free_fields(), which calls bpf_obj_free_fields().